1. Field of the Invention
The present invention relates to a keyboard, video and mouse (KVM) access over an Internet Protocol (IP) switch to a target, e.g., a server, from a remote client (a user with a desktop PC or laptop or the like) connected via a Transmission Control Protocol/Internet Protocol (TCP/IP) network.
2. Description of Related Art
Conventionally, KVM-IP devices enable access over an IP switch for a remote client by doing the following:
1) Transport video: the KVM-IP device connects to the target's video output and digitizes it for transport over the digital TCP/IP network to the client. To minimize the amount of network traffic load, the video is usually compressed using any of a variety of methods.
2) Transport keyboard and mouse: the KVM-IP device also connects to the keyboard and mouse interfaces on the target (typically either PS2 or universal serial bus USB), and relays keystrokes and mouse movements from the client to the target.
3) Status: generally, the KVM-IP device monitors status of the target and conveys it to the client.
The hardware to implement the video transport (generically referred to as an analog/digital (A/D) channel) is expensive, which is why there are conventional KVM-IP devices that connect to more targets (N) than they have A/D channels (M) and use an N×M switch to multiplex the targets to the A/D channels. This constrains the system to only accessing M targets at a time, precluding some advanced features that require continuous access to all targets. Such a system is relatively easy to configure, however, because all the networking intelligence is centralized into a single box, as exemplified by the KX216 product of Raritan Computer (illustrated schematically in FIG. 1).
An alternate approach, illustrated in FIG. 2, is to use a KVM-IP device that provides a dedicated connection to a single target (e.g., a desktop computer or server) and optionally employ a KVM gateway/aggregation device such as the Command Center Secure Gateway provided by Raritan Computer. By using one KVM-IP device for each target, all targets may be monitored simultaneously, enabling advanced features. However, this type of deployment can be cumbersome, because a large number of independent TCP/IP devices must be administered. Some standard techniques can ease the burden (dynamic host configuration protocol (DHCP), centralized management systems such as CC Secure Gateway), but two problems remain:
1) Each KVM-IP device must at some point be manually identified and associated with its connected target.
2) Each KVM-IP device must consume an IP address on the network.
It would be preferable to maintain the performance and feature advantages of the latter solution while eliminating its disadvantages.
The KIMBLE system is a project done by Raritan Peppercon that takes a cluster of eight 1×1 KVM-IP devices, and enables them to share a single IP address and behave as a single 8×8 device. Configuring the KIMBLE system requires a cluster configuration tool, which is used to assign nodes to clusters, and distribute information about a cluster to each of its members. In other words, clusters do not self-configure.
The KIMBLE system cluster selects a master processor (“master”), which then becomes the cluster's portal to the outside world. The initial connection from the client is made to the master. This connection is used for authentication and authorization, and to retrieve information about the cluster. To create a KVM connection to a particular target, the client initiates a TCP connection to the master, using a special TCP port number assigned to that target.
The master routes the packets on this connection very simply, by inspecting the incoming port number and, via a table lookup, inserting the MAC address of the desired element. For the most part, the client is unaware that it is being served by a cluster rather than a single device, but this scheme does require that the cluster may be accessed on a number of different TCP ports.
Because all elements within the cluster share the same IP address, “normal” IP communication within the cluster is not possible. Instead, an intra-cluster communication is employed. That is, the KIMBLE system starts by assigning a special, private IP address (127.1.0.x) to each element in the cluster. These addresses have significance only within the cluster. Such addresses are not allowed on the wire. Each element knows the private IP address and MAC address of each other element in the cluster, and creates static address resolution protocol (ARP) table entries for each. This is necessary because it's not allowed to ARP these addresses on the wire. The responsibility thus falls on the cluster configuration tool to distribute this information to all the cluster elements at configuration time.
When sending to a destination element within the cluster, a source element internally sets its destination IP address to the destination's private address (say, 127.1.0.5). Before appearing on the wire, the Network Address Translation (NAT) function swaps the cluster IP address in for the destination IP address (by this time, the destination MAC address has already been correctly set in the packet). The packet is then sent on the wire to the destination, routed through the intervening Ethernet switching network via the MAC address.
The destination element, upon receiving the packet, looks at the source IP address. If it is equal to the cluster IP address, it substitutes the source's private IP address in for the source IP address of the packet. The packet is then passed to the TCP/IP stacks for normal processing.
In this way, the cluster elements communicate via their private IP addresses, while only the cluster IP address appears on the wire.
FIG. 6 shows the KIMBLE intra-cluster communication, although the representation is not literally accurate as to how the TCP/IP stacks work. It does illustrate adequately how the various translations take place along the path from point A to point B.
It would be desirable to provide high performance and a high level of features to a KVM-IP product, while keeping configuration as simple as “plug and play” so that the architecture, from a configuration standpoint, looks like a simple current-generation KX, but internally hides a full TCP/IP network to accomplish its goals.